Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Мы много писали о решении VMware Cloud Disaster Recovery, которое позволяет обеспечивать катастрофоустойчивость виртуальных инфраструктур за счет резервирования онпремизных ресурсов в облаке. Службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облаке VMware Cloud on AWS.

VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.

У многих пользователей такой схемы возникает вопрос - а за что они отвечают в этом процессе, за что отвечает VMware, а за что - Amazon?

Ответ можно найти вот тут, мы расскажем об этом вкратце. Итак, VMware Cloud Disaster Recovery состоит из трех компонентов:

• Файловая система Scale-out Cloud File System (SCFS)
• Оркестратор (Orchestrator)
• Коннекторы DRaaS Connectors

VMware запустила свое DRaaS решение в октябре 2020 года и с тех пор предоставляет круглосуточную поддержку этих компонентов, включая накатывание патчей и обновлений на них.

С точки зрения безопасности и операций, ответственность распределяется по трем основным уровням - пользователь, VMware и Amazon AWS:

Пользователь отвечает за:

"Security in the Cloud":

• Безопасность в облаке при развертывании и поддержке окружений VMware Cloud Disaster Recovery
• Безопасность собственной виртуальной инфраструктуры и установку компонентов решения, необходимых для функционирования инфраструктуры катастрофоустойчивости. Также это включает в себя поддержку достаточной скорости соединения между площадками. Пользователь должен заботиться о протоколах шифрования, своевременном обновлении ПО, аудите систем, изменении паролей и всем прочем, что от него зависит.

VMware отвечает за:

"Security of the Cloud" - то есть за безопасность самого облака, что означает защиту систем и программного обеспечения, составляющего основу облака для служб VMware Cloud Disaster Recovery. Очевидно, что это включает в себя не только DRaaS-cервисы, но и платформенные составляющие, такие как VMware vSphere и vSAN.

Amazon отвечает за:

"Security of the Infrastructure" - физические серверы, доступ к ним в датацентрах, функционирование аппаратного обеспечения, исправность физических линий связи и соединений в рамках ЦОД.

Если говорить о разделении зон ответственности в плане конкретных операций и функциональности, то таблица в разрезе указанных трех сущностей выглядит так:

Более детальная информация обо всем этом приведена в документе "VMware Cloud Disaster Recovery Service Description".

В конце лета прошлого года мы писали об интереснейшем документе "VMware vSphere Snapshots: Performance and Best Practices", который содержит весьма полезную многим администраторам информацию о производительности снапшотов, а также лучшие практики по обращению с ними. Мы, кстати, часто пишем про это (1, 2, 3), и хорошо, что теперь об этом есть и подробный документ с картинками.

В конце года VMware решила обновить этот whitepaper, добавив туда немного информации о производительности снапшотов в инфраструктуре контейнеризованных приложений Kubernetes на платформе vSphere.

Тестовая конфигурация там выглядела вот так:

Соответственно, процедура тестирования выглядела так:

• Снимаем базовый уровень производительности для ВМ worker-ноды без снапшотов под нагрузкой
• Создаем снапшот ВМ worker-ноды
• Запускаем бенчмарк и получаем данные о производительности
• Увеличиваем по одному число снапшотов и повторяем цикл тестирования

Тестировались приложения Weathervane и Redis. Результаты показали, что даже при большом количестве снапшотов производительность не падает:

Больше подробностей вы можете узнать в обновленном документе "VMware vSphere Snapshots: Performance and Best Practices".

Продолжаем вам рассказывать о решении NAKIVO Backup & Replication, предназначенном для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. В прошлой статье мы рассказывали о выходе новой версии продукта, где появились функции мониторинга виртуальных сред, а сегодня поговорим о лучших практиках его использования.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

Давайте взглянем на таблицу допустимых конфигураций из вот этой статьи VMware:

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Недавно мы писали об уязвимости Log4j, затрагивающей компоненты веб-серверов Apache Software Foundation log4j Java logging, а значит присутствующей и во многих продуктах VMware. Также мы рассказывали о том, как понять, что вас сканируют на уязвимость log4j, если у вас есть VMware vRealize Network Insight.

Надо сказать, что у партнеров VMware есть такое средство, как HealthAnalyzer, которое осуществляет сбор данных с различных компонентов виртуальной среды и составляет отчет об их состоянии. Оно позволяет собрать детальную информацию о продуктах VMware Horizon, VMware vSphere и VMware NSX, которая включает в себя различные конфигурации и данные об использовании. Собранные с помощью VMware HealthAnalyzer Collector данные можно отправить партнерам VMware или в саму VMware для дальнейшего анализа.

HealthAnalyzer позволит вам обнаружить угрозы, которые описаны в статьях CVE-2021-4428, CVE-2021-45046 и CVE-2021-45105 (а это 10/10 и 7.5/10 по шкале серьезности). Однако чтобы это работало, вам нужно удалить старую версию VMware HealthAnalyzer и поставить новую с портала Partner Connect.

Чтобы удалить старую Java-версию HealthAnalyzer, нужно просто удалить ее папки и связанные файлы. Для виртуальных модулей - нужно выключить ВМ и удалить ее из инвентори.

Также если вы будете использовать предыдущую версию анализатора, то ваши регистрационные данные в форме не будут приняты:

За установкой продукта HealthAnalyzer обращайтесь к своему поставщику VMware.

Ну и бонус-видео о том, как временно обезопасить свой VMware vCenter от Log4j, пока критические фиксы еще в пути:

Компания VMware анонсировала новую версию продукта VMware HCX 4.3, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях версии 4.2 этого продукта мы писали вот тут.

Давайте посмотрим на новые возможности HCX 4.3:

1. Переход на PostgreSQL

Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.

2. Улучшения HCX Network Extension

Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.

Диаграмма ниже показывает, как работают виртуальные модули NE, которые формируют пары на каждой из площадок, а во время нормальных операций трафик использует active-туннель между модулями. Другой туннель между standby-модулями также поддерживается, но трафик по нему не идет. На него происходит переключение в случае сбоя основного канала.

HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.

3. Улучшения OS Assisted-миграций

OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:

• Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
• Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3. 

4. Улучшения юзабилити

• Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
• Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.

Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.

Мы много пишем про растянутые кластеры VMware vSAN Stretched Clusters для онпремизной инфраструктуры VMware vSphere, но не особо затрагивали тему растянутых кластеров в публичных облаках. В частности, в инфраструктуре VMware Cloud on AWS можно создавать такие кластеры, работающие на уровне зон доступности (Availability Zones).

Облачные администраторы знают, что публичное облако AWS разделено на регионы (Regions), в рамках которых есть зоны доступности (Availability Zones, AZ), представляющие собой домены отказа (аналогичные таковым в vSAN). То есть если произойдет сбой (что довольно маловероятно), он затронет сервисы только одной зоны доступности, остальные AZ этого региона продолжат нормально функционировать.

Сама Amazon рекомендует дублировать критичные сервисы на уровне разных зон доступности, а с помощью растянутых кластеров VMware vSAN можно сделать полноценную задублированную среду на уровне AZ в рамках одного региона с компонентом Witness для защиты от ситуации Split-brain, когда будет разорвана коммуникация между зонами:

Для такой конфигурации вам потребуется создать SDDC с поддержкой Stretched Cluster, который создается на этапе настройки SDDC на платформе VMC on AWS. Надо понимать, что при развертывании SDDC можно задать тип кластера Standard или Stretched, который уже нельзя будет поменять в дальнейшем.

Пользователь задает AWS Region, тип хоста, имя SDDC и число хостов, которые он хочет развернуть. Далее администратор выбирает аккаунт AWS и настраивает VPC-подсеть, привязывая ее к логической сети для рабочих нагрузок в аккаунте. Нужно выбрать 2 подсети для обслуживания двух зон доступности. Первая устанавливается для preferred-площадки vSAN, а вторая помечается как сеть для "non-preferred" сайта.

После создания кластера, когда вы зайдете в инстанс Multi-AZ SDDC vCenter вы увидите растянутый кластер vSAN с одинаковым числом узлов на каждой из AZ и один компонент Witness, находящийся за пределами данных AZ.

Такая конфигурация работает как Active-Active, то есть вы можете помещать производственные виртуальные машины в каждую из зон, но вам нельзя будет использовать более 50% дисковой емкости для каждой из облачных площадок.

Конечно же, нужно позаботиться и о защите виртуальных машин как на уровне площадки, так и на уровне растянутого кластера. Лучше всего использовать политику хранения "Dual site mirroring (stretched cluster)" на уровне ВМ. В этом случае при сбое виртуальной машины в рамках одной зоны доступности она будет автоматически перезапущена в другой AZ с помощью механизма VMware HA.

Также администратору надо контролировать физическое размещение виртуальных машин по площадкам, а также политику Failures to tolerate (FTT):

Конечно же, не все виртуальные машины нужно реплицировать между площадками - иначе вы просто разоритесь на оплату сервисов VMConAWS. Администратор должен выставить правила site affinity rules, которые определяют, какие машины будут реплицироваться, а какие нет. Делается это с помощью движка политик storage policy-based management (SPBM) для ВМ и их VMDK-дисков: 

Также более подробно обо всем этом вы можете почитать в статьях vSAN Stretched Cluster Guide и VMware Cloud on AWS: Stretched Clusters.

В конце ноября мы писали о том, что "уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3", но ситуация оказалась гораздо хуже. Никаких новостей об исправлениях для новой версии, по-прежнему, нет. Напомним, что о новых возможностях vSphere 7 U3 мы писали тут.

Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:

Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:

Если мы зайдем на статью базы знаний "Build numbers and versions of VMware ESXi/ESX (2143832)", то увидим, что последние три релиза vSphere просто зачеркнуты в таблице:

18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:

Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.

В самом интересном положении оказались пользователи, которые уже прошли процедуру апгрейда своей инфраструктуры на Update 3. Им не рекомендуют откатывать все назад (это и не так просто, к тому же), если они не сталкиваются с критичными проблемами, такими как PSOD. Однако и сроков по доступности исправлений Update 3 тоже не дают.

Ждем исправлений!

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

Компания VMware сообщает пользователям, что разобралась с проблемой, которая появилась в компоненте веб-сервера Apache Software Foundation log4j Java logging, а значит и во многих продуктах VMware. Эта уязвимость описана в CVE-2021-44228 - атакующий, который имеет доступ к отсылке логов (к отсылке самих сообщений или к настройке их параметров), может исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена. Это уязвимость типа "zero-day", а значит исправление ее еще находится в процессе.

Надо понимать, что поскольку проблема с log4j касается веб-серверов, то вам надо позаботиться о защите не только управляющих компонентов виртуальной инфраструктуры VMware, но и виртуальных и физических машин.

Итак, вот какие ресурсы помогут вам защититься от этой уязвимости:

• VMware Security Advisory VMSA-2021-0028 (главное описание проблемы и путей ее решения)
• VMSA-2021-0028 Questions & Answers (вопросы и ответы)
• VMSA-2021-0028 & Log4j: What You Need to Know (источник этого поста)
• VMware Communities Thread On CVE-2021-44228 (место, где можно задать вопросы по этой теме)
• Tips for Patching VMware vSphere & Cloud Infrastructure (практические советы по патчингу)
• VMware vSphere Security Configuration Guide (основной документ о безопасности vSphere)

Для инфраструктурного ПО VMware нужно просто убедиться в том, что у вас установлен соответствующий патч или апдейт, который не старше версии, указанной в таблице по первой ссылке:

Увы, для многих продуктов исправлений еще нет, они в процессе выпуска, поэтому до момента их накатывания следует озаботиться применением воркэраундов из рекомендаций VMware, ссылки на которые также приведены в таблице. Да, пока придется править реестр и конфигурационные файлы.

Помните, что уязвимость критическая и имеет оценку 10 из 10 по методике CVSS 3.1 (remote code execution, RCE), поэтому надо проверить все компоненты инфраструктуры уже сегодня, особенно те, что смотрят в интернет. Самым простым способом для злоумышленника будет посылка кода со страницы логина атакуемого сервиса, так как все такие действия логируются.

Ну и есть положительный момент - в облачных инфраструктурах, таких как VMware Cloud on AWS, эти проблемы уже устранены, но на стороне онпремизных облаков или небольших сервис-провайдеров они все еще могут быть.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

На сайте проекта VMware Labs обновилась полезная для администраторов VMware vSphere утилита VMware DRS Sump Insight до версии 2.1. Напомним, что это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS. О прошлых версиях этой утилиты мы писали тут и тут.

В новой верси не так много нововведений:

• Добавлена поддержка дампов VMware vSphere 7.0 Update 2 и Update 3
• Минорные улучшение интерфейса и бэкенда
• Исправления ошибок

Напомним также о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

Скачать VMware DRS Sump Insight 2.1 можно по этой ссылке.

Не так давно мы рассказывали о продукте NAKIVO Backup & Replication, который является одним из лидеров в сфере решений для резервного копирования и защиты данных виртуальной инфраструктуры, его основных возможностях и областях применения. Сегодня мы рассмотрим новые возможности версии 10.5, которая вышла недавно и доступна для загрузки.

Компания VMware объявила о выпуске технологического превью продукта Application Transformer for VMware Tanzu, который позволяет еще больше сократить разрыв между виртуализацией на уровне контейнеров и инфраструктурой серверной виртуализации.

Теперь с помощью этого решения можно упростить имплементацию стратегии 5R для модернизации корпоративных приложений: rehost, replatform, refactor, retain, retire. Начать можно с концепции replatform, которая предполагает миграцию приложений в корпоративную среду контейнеров, которая делает прозрачным и более гибким процесс развертывания и эксплуатации различных сервисов.

Application Transformer for Tanzu предназначен для решения следующих задач, касающихся legacy-приложений:  

• Discovery – утилита сканирует виртуальные машины, собирая структуру директорий, пулов ресурсов, имена приложений и процессов. Далее на основе этого выстраивается топология приложений датацентра.

• Analysis – на базе собранной детальной информации, с учетом имеющихся бизнес-требований, администраторы и менеджеры датацентра решают, каким приложениям надо мигрировать в контейнеры и в каком порядке.

• Transform – Application Transformer for Tanzu создает OCI-compliant образы контейнеров для Linux-based приложений посредством простого мастера, также в процессе поддерживаются такие сервисы, как Oracle WebLogic Server и Apache Tomcat. Выходные артефакты Kubernetes, такие как YAML-файлы, позволяют пользователям быстро развертывать образы контейнеров в кластерах VMware Tanzu Kubernetes.

Application Transformer for Tanzu работает без агентов поддерживает множество типов приложений (в базе есть более 200 сигнатур) и глубокий анализ содержимого ВМ. В список входят не только большие корпоративные приложения, такие как WebLogic и Tomcat, но и разнообразные generic Java-приложения. Утилита может получить имя приложения, состав его процессов, размещение на диске и другое.

Сам продукт использует VMware vCenter API для получения доступа к ВМ на платформе vSphere или VMware Cloud on AWS. За счет интеграции с решением VMware vRealize Network Insight, Application Transformer for Tanzu может использовать диаграмму потоков vRealize Network Insight для автоматического создания end-to-end топологий, что важно для визуализации взаимосвязей приложений.

Далее, если администратор принял решение о переводе приложения в кластер Kubernetes, Application Transformer for Tanzu предоставляет процесс на базе мастера, который автоматизирует задачи контейнеризации, такие как создание docker-файлов, генерацию образов контейнеров, сохранение их в нужный репозиторий, а также создание YAML-манифестов Kubernetes для приложений на базе Linux. Затем, если нужно развернуть приложение, можно использовать команду Kubectl для пуша OCI-образа на платформу VMware Tanzu Kubernetes.

Вот какие основные премущества дает Application Transformer for Tanzu:

• Holistic view – создание визуальных топологий через CLI/API, используя метаданные компонентов приложений и проанализированные связи между ними. 
• Efficiency through automation – уменьшение ручных операций за счет глубокой интроспекции в ВМ, создания инвентаря объектов и маппинга ВМ в рамках топологий.
• Flexibility – Application Transformer for Tanzu позволяет пользователям выбрать действия в рамках R-фреймворка на базе скоринга приложений.
• Increased agility and speed to market – Application Transformer for Tanzu уменьшает время и уменьшает затраченные ресурсы на модернизацию старых приложений, которых в больших компаниях довольно много. Также утилита уменьшает и время на ввод в эксплуатацию старых и новых приложений в унифицированную среду контейнеров.

Более подробно о VMware Application Transformer for Tanzu можно почитать на странице продукта. Application Transformer for VMware Tanzu доступен как для облачной инфраструктуры VMware Cloud on AWS, так и для онпремизной VMware vSphere. Для системных интеграторов будет доступен бесплатный NFR-ключ.

Как все из вас знают, не так давно компания VMware выпустила обновление своей серверной платформы виртуализации vSphere 7 Update 3. Мы писали также о нововведениях в отношении хранилищ, обновлении 3a, новых возможностях продукта vSAN 7 U3 и обновлениях vCenter и vSphere Client.

Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.

Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:

1. Масштабируемость виртуальных машин

Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:

2. Оптимизации рабочих нагрузок, чувствительных к задержкам

Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.

3. Технология vSphere Memory Monitoring and Remediation (vMMR)

Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).

С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.

4. NVMe over TCP/IP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.

Больше подробностей о производительности VMware vSphere 7 вы найдете в документе "What’s New in Performance for VMware vSphere 7?".

Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:

Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.

Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.

Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:

Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.

Помните, любое обновление продуктов VMware надо проводить только по прошествии нескольких недель, в течение которых нужно следить за появившимися сообщениями о серьезных багах. Эта ситуация повторяется из релиза в релиз, а опытные пользователи vSphere к такому образу действий уже привыкли.

Некоторые Enterprise-администраторы знают, что у VMware есть такой сервис Skyline, предназначенный для проактивного получения рекомендаций по технической поддержке продуктов линейки VMware vSphere, включая vSAN. В частности, с помощью VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению.

Skyline Advisor Pro построен на базе ранее существовавшего продукта Skyline Advisor, который доступен пользователям подписок Production и Premier, vRealize Cloud Universal, а также Success 360. С помощью этого решения пользователи могут получать проактивную аналитику для своей виртуальной инфраструктуры в целях идентификации текущих и будущих проблем. Оно поддерживает не только продукты vSphere, vSAN, NSX, vROps и Horizon, но и среды Cloud Foundation и Dell EMC VxRail.

Давайте взглянем на новые возможности этого продукта.

1. Теперь Skyline Advisor Pro работает быстрее.

В Skyline Advisor Pro реализован движок ускоренного анализа инфраструктуры, понимания необходимости обновлений и отслеживания изменений. Теперь вместо 48 часов в прошлой версии, сбор проблемных моментов и изменений inventory занимает 4 часа, что позволяет быстрее реагировать на инциденты и удобнее планировать активности администраторов по решению проблем (картинка - кликабельный gif):

2. Улучшения движка аналитики

Теперь Skyline Advisor Pro дает больше инсайтов об окружении, например, появился новый раздел End of Life Insights. В нем показывается, когда ваши развернутые решения больше не будут поддерживаться (окончание фаз General Support и Technical Guidance) в плане выпуска патчей, апдейтов и багофиксов. Эта возможность часто запрашивалась пользователями, чтобы дать возможность планирования своевременных апгрейдов виртуальных сред.

Кликните на картинку, чтобы открыть gif:

3. Функция Historical Insights

С помощью исторических данных Historical Insights администраторы могут ассоциировать некоторые ключевые события в своем окружении (например, изменения конфигурации) с рекомендациями, которые были сгенерированы в этот отрезок времени. Это позволяет в ретроспективе оценить полезный эффект от применения рекомендаций.

Посмотрите, как это работает (картинка кликабельна):

4. Функция Proactive Insights Report for Success 360

Она доступна только пользователям подписки Success 360 и предоставляется отдельной командой ИТ-специалистов VMware. Отчеты Proactive Insights генерируются при ее участии и могут быть использованы для регулярных проверок состояния виртуальной среды (там указаны конкретные действия по улучшению, которые были предприняты, а также еще имеющиеся рекомендации).

Также в этих отчетах доступно поле Resolution Type, которое определяет примерный объем усилий, которые нужно приложить для исправления проблемы. Например, применение некоторых рекомендаций не требует перезагрузки и их можно сгруппировать в единый пакет, применив который можно уже переходить к более "тяжелым" рекомендациям.

Ну и полезной также является возможность оставлять комментарии и пожелания о том, что планируется или хотелось бы сделать, чтобы совместно корректировать траекторию по оптимизации инфраструктуры (картинка кликабельна):

5. Новый Insights API

Теперь Skyline Advisor Pro предоставляет Insights API, который предоставляет данные Findings и Recommendations через программный интерфейс для любых сторонних решений в вашей инфраструктуре. Например, данные Findings можно отправить в Slack или создать тикет в ITSM-системе на базе информации, предоставленной Skyline Advisor Pro. Вот как это работает (кликните на картинку):

Также о работе Insights API есть отдельное видео:

Более подробно о продукте и сервисах VMware Skyline Advisor Pro можно узнать на этой странице.

В начале осени, в рамках прошедшей конференции VMworld 2021 Online, компания VMware представила свое виденье развития концепции виртуализации и агрегации хранилищ корпоративных инфраструктур - Federated Storage Platform (FSP).

Проблема современного подхода к организации хранилищ состоит в том, что аппаратные комплексы в датацентре представлены разными моделями, производителями, а также поколениями в рамках одной продуктовой линейки. Ввиду этого администраторам приходится разрабатывать набор административных регламентов по обслуживанию жизненного цикла таких хранилищ - ввод в эксплуатацию, развертывание новых сервисов, обеспечение высокой доступности и план по изменению емкостей - вывод устаревших систем и расширение существующих емкостей. Ко всему этому добавляются Day-2 Operations и обеспечение безопасности хранения данных виртуальных и физических сред.

Как итог - корпоративная инфраструктура предприятия не может обеспечить те же преимущества, что и унифицированная облачная среда, которая избавляет администраторов от заботы об оборудовании и, в частности, хранилищах.

Проблему отчасти решает подход к организации гиперконвергентной инфраструктуры (Hyperconverged Infrastructure, HCI), например, концепция HCI Mesh. Но этого было недостаточно, и VMware запустила радикальную инициативу - Federated Storage Platform (FSP) - решение, которое приведет к унификации операций онпремизных и облачных сред в плане хранилищ за счет их виртуализации и агрегации.

С помощью VMware FSP можно будет управлять любым числом хранилищ разных вендоров, с которыми работает любое количество управляющих серверов vCenter:

Здесь будет 2 ключевых сущности:

• Common volumes - это новый слой представления ресурсов хранения от гетерогенных кластеров vSAN, томов vSphere Virtual Volumes дисковых массивов, а также NFS-массивов. Все это будет объединено на уровне пулов.
• Data center control plane - новый слой управления инфраструктурой хранения на базе эластичных пулов с возможностью полного доступа к имеющимся емкостям. Все это позволит видеть ресурсы хранения как в облаке, безотносительно имеющихся моделей массивов и топологий.

FSP будет полностью интегрирован в уже имеющимся механизмом политик хранения SPBM (vSphere Storage Policy Based Management), предоставляя гибкие пулы хранения для уровня приложений на базе их потребностей. Платформа VMware vSphere будет выступать как один из потребителей ресурсов в рамках этой концепции.

Для обеспечения различных уровней сервиса будут работать расширенные политики FSP, такие как квоты на емкости и ограничения по производительности, чтобы обеспечить ярусность хранения и работы с данными.

В рамках FSP процесс добавления или списания хранилищ будет бесшовным, то есть не вовлекать физическую коммутацию, которая будет выводиться за рамки процесса управления единым пулом хранилищ. Например, FSP может автоматически обнаружить новое уже подключенное хранилище, после чего добавить его в общий federated пул и начать балансировку нагрузок посредством VMware vSphere Storage vMotion.

Сейчас администраторам приходится вручную выполнять операции SVMotion для ввода новых хранилищ в эксплуатацию и их вывода, а FSP будет делать все это автоматически в "lazy"-режиме, чтобы обеспечивать уровень производительности виртуальной среды.

FSP будет интегрирована с драйвером vSphere CSI в Kubernetes, а также технологией CNS (Cloud Native Storage). Разработчики смогут потреблять дисковые емкости в рамках классов через FSP, а администраторы получать полную видимость использования таких хранилищ на уровне всего датацентра.

Сейчас решения VMware vSphere with VMware Tanzu и TKG-S VMware Tanzu Kubernetes Grid могут развертывать рабочие нагрузки в рамках пространств имен кластера, а FSP даст возможность развернуть приложения на любом хранилище в любом кластере на базе любых доступных политик.

Сейчас с помощью x-vMotion виртуальную машину можно перемещать между кластерами и разными инфраструктурами vSphere. FSP расширит эти возможности, позволяя виртуальным машинам и контейнеризованным приложениям свободно "путешествовать" между кластерами, инфраструктурами и пространствами хранения - при этом под полным контролем управляющего слоя.

Получить больше информации об инициативе можно из записи этой ссессии с прошедшего VMworld 2021 Online: VMware’s vision for storage and data in a multi-cloud world.

В начале октября компания VMware представила платформу Tanzu Community Edition. Это такой бесплатный open source дистрибутив VMware Tanzu, который поддерживается со стороны открытого сообщества, а устанавливается за считанные минуты на локальную рабочую станцию или в облаке.

Появление Tanzu Community Edition - это часть стратегии VMware по популяризации своего решения для работы с кластерами Kubernetes среди инженеров, которые могут осваивать эту платформу бесплатно, а потом уже переходить на коммерческие решения, если у компаний появляется в этом необходимость.

Многие инженеры знают, что различные компоненты инфраструктуры Kubernetes не так-то легко развернуть и начать использовать (например, взгляните на инфографику Cloud Native Computing Landscape), поэтому VMware в решении Tanzu Community Edition сделала упор на простоту развертывания и эксплуатации компонентов, сохраняя при этом Enterprise-возможности решения.

Эта экосистема содержит набор проверенных решений, которых вам будет достаточно для организации доставки сервисов Kubernetes в контейнеризованных приложениях, а также мониторинга этой инфраструктуры.

Самый важный момент тут в том, что эту среду, которую сейчас вы используете для экспериментов и первых развертываний, потом можно будет перевести на коммерческие издания VMware Tanzu без каких-либо потерь.

Tanzu Community Edition - это полностью бесплатное open source решение, которое не ограничено ни с точки зрения использования ресурсов, ни с точки зрения функциональности. В нем нет ограничений по времени использования и недоступных функций, которые открываются при покупке полной версии решения - продукт можно использовать сразу и в производственной среде.

Если вам не хочется проводить процедуры по развертыванию компонентов, то VMware предлагает попробовать Tanzu Community Edition в песочнице. Также для администраторов доступны обучающие материалы с ресурсов KubeAcademy и Tanzu Developer Center. Ну и, конечно же, не надо забывать об образовательном потенциале самого сообщества вокруг бесплатного продукта.

За несколько минут можно развернуть Tanzu Community Edition на платформе VMware vSphere, в публичном облаке (например, Amazon AWS), либо вообще на локальной рабочей станции.

Очевидно, что основное назначение Tanzu Community Edition в бесплатном варианте - это эксперименты, обучение администраторов, подготовка к сертификациям по Kubernetes и прочее, но для создания первых компонентов инфраструктуры контейнеров приложений этого будет вполне достаточно.

Скачать VMware Tanzu Community Edition можно по этой ссылке. Ну а о том, как начать развертывать и использовать данную платформу, написано вот в этой статье блога VMware.

Update: вот еще отличное видео о том, как начать работу с VMware Tanzu Community Edition:

Какое-то время назад мы писали о возможностях платформы виртуализации VMware vSphere 7 Update 3, где появилось немало всего нового. Но, помимо заметных нововведений, было сделано немало и небольших улучшений, которые влияют на удобство использования vSphere Client для управления серверами VMware vCenter.

Давайте посмотрим на интерфейс рекомендаций VMware DRS в VMware vSphere 7 Update 2 и ниже, который находится вот тут: Cluster UI > Monitor > DRS Recommendations:

Видно, что интерфейс был так себе, поэтому в Update 3 его переделали:

Теперь в гриде мы видим список действий для данной рекомендации, появились элементы Select All и Clear Selection, ну и в целом все стало выглядеть намного приятнее.

Также это хорошо смотрится и в темной теме vSphere Client:

Кроме того, было улучшено и окно настройки механизма Proactive HA. Раньше оно выглядело вот так:

Это было довольно ненативно - нясно, включен ли соответствующий провайдер, и какие условия для него работают. Теперь же отдельным переключателем включается провайдер:

А когда он включен, соответствующими переключателями можно настраивать условия отказов:

При этом доступны и операции над всеми переключателями - Block All и Unblock All.

На самом деле, подобные улучшения происходят часто и в минорных релизах VMware vSphere - команда UI в VMware постоянно старается сделать жизнь администраторов проще и приятнее.

На сайте проекта VMware Labs появилось еще одно полезное средство для администраторов виртуальной инфраструктуры - vSphere Diagnostic Tool. Оно представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Интересно, что данный продукт уже был протестирован во внутренней команде поддержки VMware, которая опробовала его на реальных пользователях.

Для vCenter Server Appliance 6.5 или более поздней версии можно выполнить следующие тесты:

• Базовая информация о vCenter
• Проверка Lookup Service
• Проверка AD
• Проверка сертификатов vCenter
• Проверка основных файлов (Core File)
• Проверка диска
• Проверка vCenter DNS
• Проверка vCenter NTP
• Проверка портов vCenter
• Проверка аккаунта Root
• Проверка служб vCenter
• Проверка механизма VCHA

В качестве результатов будет выдан один из статусов Pass/Warning/Fail, а также для статусов Warning и Fail выводятся ссылки на статьи KB, которые могут пригодиться для решения проблем в данной категории.

Команда заявляет, что в бэклоге проекта еще более 100 планируемых фич, поэтому следите за обновлениями скриптов. Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать vSphere Diagnostic Tool можно по этой ссылке.

Недавно мы писали о продукте NAKIVO Backup & Replication, который является одним из лидеров в сфере решений для резервного копирования и защиты данных виртуальной инфраструктуры. Мы рассказали об основных его возможностях и областях применения, а сегодня мы подробно остановимся на его использовании при защите от программ-вымогателей (Ransomware)...

Как некоторые из вас знают, у компаний VMware и Microsoft есть совместное предложение облачных услуг Azure VMware Solution (AVS). Платформа AVS предоставляет клиентам облачной IaaS-инфраструктуры Azure полный комплект облачных решений VMware стека SDDC, таких как vSphere, vSAN, NSX-T и других, которые бесшовно интегрированы в Microsoft Azure. Все это позволяет крупным компаниям строить гибридные инфраструктуры с единым набором инфраструктурных решений между онпремизной площадкой и облаком Azure. Не так давно это облако стало доступно и на базе VDI-решения VMware Horizon.

Недавно VMware выпустила 3 интересных лабораторных работы (они же Hands-On Labs, HoL), пройдя которые вы сможете узнать об этом решении больше и пройти через выполнение различных задач в интерфейсах облака AVS.

• Azure VMware Solution – Lightning Lab (Deployment and Connectivity) 

Это просто вводный модуль на 30 минут для самых новичков, отлично подойдет, чтобы узнать базовые вещи про это облако и погрузиться в тему:

• Disaster Protection with Azure VMware Solution and VMware Site Recovery Manager

Эта лаба будет полезна тем, кто хочет больше узнать об использовании облака AVS как Disaster Recovery решения, которое возьмет на себя нагрузку в случае сбоя в собственном облаке на базе VMware vSphere. Модуль также длится 30 минут:

• VMware SD-WAN for Azure VMware Solution 

Это уже довольно серьезная лабораторная работа, состоящая из 5 модулей по 15 минут, где рассматриваются различные аспекты построения сетей SD-WAN и архитектуры Virtual Cloud Network, а также перестроения существующих сетей для работы этих технологий.

Полный список доступных лабораторных работ VMware Hands-On Labs можно посмотреть здесь.

Недавно компания VMware провела тестирование баз данных PostgreSQL в качестве рабочей нагрузки в виртуальных машинах vSphere 7.0 U2 с использованием памяти Intel Optane DC persistent memory (PMem). Напомним, что именно на этот тип памяти компания VMware ориентируется при разработке технологии Project Capitola.

Память Intel Optane DC persistent memory (DCPMM она же PMEM) не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.

В качестве тестового стенда использовалась следующая конфигурация хоста ESXi и виртуальных машин:

Память PMEM была презентована виртуальным машинам как очень быстрое устройство хранения (NVDIMM). Конфигурация PostgreSQL была следующей:

VMware использовала 3 различных конфигурации для тестирования:

• 2 устройства NVME SSD (это базовый уровень) - оба раздела, WAL и база данных, были на двух разных быстрых SSD
• WAL на базе PMEM - раздел WAL поместили на 200-гигабайтное устройство PMem NVDIMM
• WAL и база данных на PMem - все разделы были размещены на устройствах PMem NVDIMM

В виртуальной машине запускали стресс-тест базы данных со значительной нагрузкой на диск, средней нагрузкой на систему и интегрированными транзакциями. Пропускная способность (throughput) измерялась в количестве транзакций в секунду (TPS).

Вот что из этого вышло:

По итогу теста для полной нагрузки на PMEM по сравнению с SSD пропускная способность выросла на 44.6%, а задержка (latency) упала на 30.8% (при перенесении только WAL на PMEM эти показатели составили 13.4% и 11.8%, соответственно).

Те же самые параметры для read-only транзакций:

Тут уже разница более, чем в 3 раза. Также VMware попробовала машину с 1 ГБ оперативной памяти вместо 200 ГБ - там улучшение было еще больше, а среднем PMEM дает улучшение производительности по сравнению с SSD в районе 4.5x.

Полное описание процедуры тестирования находится тут.

Компания VMware, вскоре после большого обновления vSphere 7 Update 3, выпустила небольшой апдейт vSphere 7 U3a. С момента прошлого релиза прошло около месяца, поэтому нововведений не так много. Напомним, что в Update 3 для администраторов и DevOps появилась возможность использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Теперь в Update 3a эта возможность позволяет вновь созданным виртуальным машинам стать частью кластера TKG (Tanzu Kubernetes Grid) с нативным исполнением команд. Это позволит:

• Компаниям использовать кластеры TKG как платформу Kubernetes с GPU-ускорением для нагрузок AI/ML.
• Администраторам получить инструмент быстрой и эффективной совместной работы над развертыванием и обслуживанием инфраструктуры контейнеров и уйти от рабочего процесса коммуникации на базе тикетов.

Инфраструктура Tanzu Kubernetes (TKr) теперь построена на Ubuntu 20.04 - сам образ был оптимизирован для использования с нагрузками AI/ML и тщательно оттестирован. Детальное руководство об использовании сервисов Tanzu для AI/ML находится в этой статье.

Также обновление содержит патч VMware vCenter Server Appliance 7.0 Update 3a, который включает в себя фиксы ошибок и исправления в подсистеме безопасности.

Скачать VMware vSphere 7 Update 3a можно по этим ссылкам:

• VMware vCenter 7 Update 3a
• VMware ESXi 7 Update 3a

Release Notes находятся тут.

Недавно компания VMware выпустила обновление VMware vSphere 7 Update 3, которое стало доступным для загрузки накануне уже прошедшей конференции VMworld Online 2021. В рамках конференции VMware рассказала о перспективах развития технологий своих серверных и десктопных продуктовых линеек, в которых ожидается много интересных нововведений в самом ближайшем будущем. Сегодня мы поговорим о трех основных анонсах...

Компания VMware завтра уже закрывает регистрацию пользователей в Content Catalog главной онлайн-конференции о виртуализации VMworld 2021, которая проходила на прошлой неделе.

On-demand видеосессии уже доступны для просмотра, как и PDF-презентации, которые можно скачать для детального изучения технических сессий:

Сейчас в каталоге около 800 сессий, поэтому все посмотреть не получится. Коллеги из VMware рекомендуют следующие сессии для того, чтобы узнать о новых продуктах и технологиях, ну и в целом, чтобы "быть в теме":

• VMworld General Session [GEN3103]

App Modernization

• Transforming Customer Experiences with VMware’s App Modernization Platform [APP1319]
• Cloud Infrastructure Transformation with VMware Tanzu Basic and Tanzu Standard[APP2454]
• Manage Kubernetes Across Multiple Clouds [APP1187]

Anywhere Workspace

• Digital Employee Experience: The Key to a Successful Anywhere Workspace [EUS2069]
• How to Support a Remote Workforce with Workspace ONE Assist [EUS1723]
• Solution Keynote Part 1: Vision and Announcements[EUS2470]

Multi-Cloud

• Solution Keynote: DevSecOps Your Way to Any Cloud (And Delight Customers) [VI3190]
• Best Practices for Running AI Workloads in VMs on VMware vSphere [VI1459]
• Project Monterey: Present, Future and Beyond [MCL1401]
• How vSphere Is Redefining Infrastructure For Running Apps In the Multi-Cloud Era [MCL2500]

Security 

• A Practical Approach for End-to-End Zero Trust [SEC2733]
• Solution Keynote: Simplify Security Complexity [SEC2732]
• Innovations in Ransomware Defense for Today’s Multi-Cloud Environments [SEC2608]

Networking

• A Modern Network: In-Cloud and Cloud-to-Cloud Connectivity as a Service [NET2692]
• App Owners Say the App Is Slow and the Network Is to Blame. What Do You Do? [NET1796]
• Bring Public Cloud Agility to Load Balancing in Any Environment [NET2694]

Edge

• Solution Keynote: The Future of Distributed Enterprise Edge Runs through Service Providers [EDG3058]
• Dish is Empowering Limitless 5G Innovation in a Cloud Native World [EDG2595]
• Edge Computing Will be the Fastest Monetizing Service for CSPs [EDG2594]

Vision & Innovation 

• Build a Self-Service Big Data Analytics Platform on VMware [VI1821]
• Edge Computing in the VMware Office of the CTO: Innovations on the Horizon [VI2484]
• Next-Generation Machine Learning with VMware: FML [VI1860]

Inspire Change

• Any App, Any Cloud, Any Device Is Not Enough – We Need to Add Any User [IC1351]
• Connect Humanity – Broadband for All [IC1924]
• Data Center Sustainability Strategies: A Win for Your Budget and the Planet [IC2217]

Ищите сессии с пометкой "Demo" - их интереснее всего смотреть:

Сегодня последний день, как еще можно зарегистрироваться бесплатно по этой ссылке.

В рамках конференции VMworld 2021 было сделано не только немало анонсов новых технологий и инициатив VMware, но и объявлено о выпуске новых версий некоторых продуктов. В частности, VMware сделала доступной для загрузки новую версию платформы vRealize Automation 8.6, которая предназначена для автоматизации рутинных операций в облаке на базе VMware vSphere. О прошлой версии vRA 8.5 мы детально рассказывали вот тут.

Давайте посмотрим, что нового в vRA 8.6:

1. Поддержка VMware Cloud Director

Теперь доступен Cloud Account, который открывает интеграцию с решением Cloud Director. Теперь внутри vRA поддерживаются такие объекты, как Virtual Data Center, сети, изменение политик хранилищ и конфигураций ВМ, образы, сами ВМ и их диски и многое другое. Также со стороны vRA можно выполнять day-2 операции, такие как включение ВМ, снапшоты и управление дисками. Развертывание доступно через шаблоны Cloud Templates, а операции жизненного цикла можно осуществлять как через vRA, так и через VCD.

Более подробно о поддержке Cloud Director написано в этой статье.

2. SDDC-модули SaltStack Config для vSphere, VMC и NSX

Новые модули SaltStack SDDC теперь доступны как Open Source. Они сфокусированы на продуктовой линейке vSphere, VMware Cloud on AWS и NSX. Возможности работы с ними включают в себя различные сценарии операций day-0 и day-2, такие как создание SDDC, просмотр правил безопасности VMC, настройка NSX-T manager, конфигурация кластера vSphere и многое другое. Эти модули доступны на GitHub и могут быть использованы всеми пользователями Salt и SaltStack Config.

Более подробно об этом рассказано здесь.

3. Кастомные ресурсы с действиями ABX Actions

Теперь можно создавать Custom Resources на базе действий ABX extensibility в рамках операций жизненного цикла и контекстных действий day-2. До этого администраторы были ограничены только существующим инвентарем vRO для этого. Теперь для новых действий потребуется новый плагин или динамический тип, чтобы работать с новыми типами ресурсов. С помощью этой фичи можно создавать, читать, обновлять и удалять действия жизненного цикла и day-2 actions за счет создания ABX actions.

Об этой возможности также есть подробная статья вот тут.

4. Рабочее пространство Kubernetes в Code Stream

Рабочее пространство (Workspace) в отображении Code Stream представляет собой sandbox-окружение, которое позволяет исполнять задачи Continuous Integration tasks из пайплайна. С помощью этой функции пользователь может выбрать Kubernetes endpoint и запустить исполнение пайплайна в Kubernetes, либо же в Docker endpoint.

Более подробно об этом написано тут.

5. Dynamic vRO inputs в шаблонах Cloud Templates

В этом обновлении пользователи могут использовать dynamic inputs в нативном окружении шаблонов vRA Cloud Templates. Нужно просто выставить внешний источник ввода, добавить существующее действия и включить динамические значение на базе vRO workflow.

Как это делается в деталях вы можете узнать вот тут.

6. Настройки IPAM в шаблоне Cloud Template

Настройки IPAM, включая адреса шлюзов, домена, доменов DNS и DNS search - теперь настраиваются через шаблон Cloud Template. Эти настройки хранятся как часть machine schema и NIC properties. Эта опция доступна для типов машин vSphere, где используется статическая IP-адресация.

7. Политика Resource quota policy для изменений в операциях day-2

Политика квот ресурсов теперь применяется к изменениям day-2, касающихся CPU, памяти или хранилища, включая действия resize. Использование ресурсов обновляется в соответствии с изменениями и применяется на базе выставленной квоты на уровне Project или Org.

8. Сети vSphere теперь включены в onboarding plan

Рабочий процесс Workload onboarding теперь поддерживает сети vSphere, привязанные к объектам deployments. До этого поддерживалась только IP-информация и IP allocation/de-allocation. Теперь все сети vSphere видимы на deployment canvas, а конфигурации могут включать в себя day-2 операции в рамках процесса онбординга.

9. Добавлена роль Project Supervisor для проектов

Для объектов Projects добавлена новая роль Project Supervisor, он позволяет ускорить процесс утверждения (Approval). До этого нужно было неадминистративным пользователям применять специальную политику approval policy. Теперь специальный пользователь Project Supervisor может делать утверждение deployments, когда данная роль настроена в политике.

10. Изменение сетевых настроек виртуального модуля vRA appliance

Теперь у вас есть возможность изменить IP-адрес виртуального модуля vRA. Эта потребность часто возникает в сценариях восстановления после сбоя, особенно при использовании Site Recovery Manager. Теперь vRA поддерживает восстановление без использования растянутых (stretched) сетей.

Более подробно о новых возможностях VMware vRealize Automation 8.6 можно узнать из Release Notes. Скачать vRA 8.6 можно по этой ссылке.

На прошедшей онлайн-конференции VMworld 2021 компания VMware представила много новых интересных инициатив, продуктов и технологий. О некоторых из них мы уже рассказали в наших статьях:

• Анонсы VMware VMworld 2021: что нового в инфраструктуре DR-as-a-Service (DRaaS)?
• Анонсы VMware VMworld 2021: новые возможности платформы Workspace ONE Intelligence for Horizon

Сегодня же мы поговорим о новом начинании VMware - Project Capitola. На рынке серверной виртуализации уже довольно давно развивается экосистема оперативной памяти различных уровней - стандартная DRAM, технология SCM (Optane и Z-SSD), модули памяти CXL, память PMEM, а также NVMe. По аналогии с сетевой инфраструктурой, где есть решение NSX для виртуализации и агрегации сетей, серверной инфраструктурой (где виртуализацией CPU занимается платформа vSphere) и инфраструктурой виртуализации хранилищ vSAN, компания VMware представила среду агрегации и виртуализации оперативной памяти - Project Capitola.

Это - так называемая Software-Defined Memory, определяемая в облаке (неважно - публичном или онпремизном) на уровне кластеров VMware vSphere под управлением vCenter:

Вся доступная память серверов виртуализации в кластере агрегируется в единый пул памяти архитектуры non-uniform memory architecture (NUMA) и разбивается на ярусы (tiers), в зависимости от характеристик производительности, которые определяются категорией железа (price /performance points), предоставляющей ресурсы RAM.

Все это позволяет динамически выделять память виртуальным машинам в рамках политик, созданных для соответствующих ярусов. Для Capitola обеспечивается поддержка большинства механизмов динамической оптимизации виртуального датацентра, таких как Distributed Resource Scheduler (DRS).

Вводить в эксплуатацию свои решения в рамках проекта Capitola компания VMware будет поэтапно: сначала появится управление памятью на уровне отдельных серверов ESXi, а потом уже на уровне кластера.

Очевидно, что такая технология требует поддержки на аппаратном уровне - и VMware уже заручилась поддержкой некоторых вендоров. В плане производителей памяти будет развиваться сотрудничество с Intel, Micron, Samsung, также будут интеграции с производителями серверов (например, Dell, HPE, Lenovo, Cisco), а также сервис-провайдерами (такими как Equinix).

Главная часть сотрудничества VMware - это взаимодействие с компанией Intel, которая предоставляет такие технологии, как Intel Optane PMem на платформах Intel Xeon.

Для получения подробностей смотрите следующие сессии с прошедшего VMworld 2021 (найти их можно тут):

• [MCL2384] Big Memory – An Industry Perspective on Customer Pain Points and Potential Solutions
• [MCL1453] Introducing VMware’s Project Capitola: Unbounding the "Memory Bound"

Ну а если вам хочется узнать больше о работе с памятью платформы vSphere в принципе, то есть еще и вот такие сессии:

• How vSphere Will Redefine Infrastructure to Run Future Apps in the Multi-Cloud Era [MCL2500]
• The Big Memory Transformation [VI2342]
• Prepared for the New Memory Technology in Next Year’s Enterprise Servers? [VI2334]
• Bring Intel PMem into the Mainstream with Memory Monitoring and Remediation [MCL3014S]
• 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
• Chasing Down the Next Bottleneck – Accelerating Your Hybrid Cloud [MCL2857S]
• Implementing HA for SAP HANA with PMem on vSphere 7.0U2 [VI2331]
• 5 Key Elements of an Effective Multi-Cloud Platform for Data and Analytics [MCL1594]

Будем держать вас в курсе о дальнейших анонсах инициативы Project Capitola компании VMware.